Modern mobile applications (apps) are UI-centric; for an application (app) to be successful, first and foremost the app needs to have a visually appealing and user-friendly UI design. As such, there has been an escalation in the sophistication of UI designs for popular apps. For instance, PANDORA, a top music streaming app in GOOGLE PLAY, re-designed its user interface in version 7.1 with a more appealing theme and more dynamic transitions, which received positive feedback in major online forums and among its users. The importance is further evidenced by GOOGLE's recent push for MATERIAL DESIGN, a visual language that promotes and directly helps developers with good UI design.
However, visually appealing UI design often comes at a lofty energy cost. A recent study on 55 ANDROID apps identifies 131 most energy-greedy APIs, out of which 49 (37%) fall into the “GUI & Image Manipulation” category.
On modern mobile systems such as ANDROID, to update the screen content, apps simply issue calls to public APIs exposed by UI components, known as UI updates; while the actual graphics rendering process is handled by the framework, which is transparent to app developers. Thus to understand and optimize the energy drain due to app UI updates, app developers need to answer two fundamental questions: Q1: What visual effect did each UI update issued from app source code create, if any? Q2: What is the associated energy cost of each UI update?
Answering these questions, however, is challenging. Apps issuing UI updates to the display hardware displaying updated content goes through the entire graphics rendering process, which is highly complex on modern mobile platforms such as ANDROID for at least four reasons: (1) Crossing the entire vertical system stack: The rendering process involves traversing the entire vertical stack of all system layers from the app, the framework Java code and native code, the OpenGL ES library, and finally to the GPU, before the frames are displayed by the display hardware. (2) Asynchrony across layers: The interactions between adjacent layers are highly asynchronous, e.g., through callback posting and invocation. (3) UI update batching: Multiple UI updates issued by the app within the same display refresh interval (every 16.7 ms) are batched before asynchronously being sent to the framework layer below. (4) “Black-box” GPU: The GPU which renders the actual frames is a “black-box” hardware with closed-sourced drivers and internal command executions independent of the CPU call stacks.
Many mobile app diagnostics tools exist, including app energy profilers and graphics profilers. Such tools can profile method calls, events, and/or resource usage from certain layers, but none of them can perform profiling across the whole vertical system stack and stitch together profiling information across all the layers in order to perform holistic profiling of app UI visual effects and energy drain due to UI updates issued by the app.
The lack of holistic graphics energy profiling tools has led to the gloomy status-quo: by and large developers today are not aware of the energy implications of the UI operations issued by the app, and largely ignore the energy aspect of the UI design. Therefore, improvements are needed in the field.
There is therefore an unmet need to determine energy usage of a graphics UI update and to determine if there are any energy bugs associated with the UI update.